Skip to content

feat(18): adopt the shared CLI helpers in screen.py - #25

Merged
tdudgeon merged 1 commit into
mainfrom
feat/18-adopt-cli-helpers-in-screen
Aug 11, 2026
Merged

feat(18): adopt the shared CLI helpers in screen.py#25
tdudgeon merged 1 commit into
mainfrom
feat/18-adopt-cli-helpers-in-screen

Conversation

@tdudgeon

Copy link
Copy Markdown
Collaborator

Follow-up to #24, which migrated the other seven rdkit Jobs but left screen.py
out because of a short-flag collision. Per the decision on that PR, -d is
dropped from --descriptor and screen.py now takes the shared group.

Summary

  • --descriptor loses its -d short form, freeing -d for the group's
    --delimiter. The manifest passes --descriptor long-form
    (data-manager/rdkit.yaml:971), so it needs no change. The in-file usage
    example was updated too.
  • Adopts rdkit_utils.add_common_molecule_io_args(parser, output_required=True)
    and add_reporting_args(parser), replacing 9 hand-typed options.

Net −15/+10 lines.

⚠️ -d now means --delimiter, silently

This is the cost of the decision and worth being explicit about. -d still
parses — it just binds to a different option:

$ screen.py ... -d rdkit
-d rdkit now parses as: delimiter='rdkit', descriptor='rdkit'

So an existing script or habit passing -d <descriptor> does not error; it
silently sets a nonsense delimiter and falls back to the default descriptor. The
Job manifest is unaffected, but anyone invoking screen.py directly should know.
If that trade is unwelcome, the alternative remains giving the helper a knob to
omit -d.

A latent crash this would have introduced

screen.py's --delimiter defaulted to '\t'; the shared group defaults to
None. The manifest passes --delimiter only conditionally
({% if separatorInputs is defined %}) while --write-header is separately
conditional — so a real invocation with headerOutputs set and
separatorInputs unset would have reached:

outf.write(delimiter.join(headers) + '\n')   # AttributeError: 'NoneType'

parser.set_defaults(delimiter='\t') after the helper call preserves the
existing default exactly. Verified: with no --delimiter, both old and new
parse to '\t'.

ProgressReporter is not used here

This Job's progress message carries a hit count —
"Processed {} records, {} hits" — which report() does not emit. Swapping it
in would have quietly dropped that. The inline loop stays; --interval still
comes from add_reporting_args().

Verification

Check Result
End-to-end run vs main (queries file, tab, id-column, write-header, threshold, interval) byte-identical, 39 lines
Parsed namespace vs main only the intended differences: id_column '1'1, mol_column 0None, new omit_fields key
--delimiter default with --write-header '\t' on both — crash path closed

One scenario fails on both old and new: --queries-file with
--write-header and no --queries-delimiter raises IndexError inside the
query reader. Pre-existing and unrelated to this change.

jote was not run — needs the informaticsmatters/vs-prep image rebuilt.

🤖 Generated with Claude Code

Frees -d by dropping it from --descriptor, which lets screen.py take
rdkit_utils.add_common_molecule_io_args() like the other seven rdkit Jobs.
The manifest passes --descriptor long-form, so it needs no change.

screen.py's --delimiter defaulted to '\t' where the shared group defaults to
None, and the manifest passes --delimiter only when the user sets it. Left
alone, a run with --write-header and no --delimiter would have reached
delimiter.join(headers) with None. parser.set_defaults(delimiter='\t')
preserves the existing default exactly.

ProgressReporter is not used here: this Job's progress message carries a hit
count ("Processed N records, M hits") that report() does not emit, so the
inline loop stays. --interval still comes from add_reporting_args().

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@tdudgeon
tdudgeon merged commit 14fa4a2 into main Aug 11, 2026
12 checks passed
@tdudgeon
tdudgeon deleted the feat/18-adopt-cli-helpers-in-screen branch August 11, 2026 13:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant